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Abstract 

NASA is proposing increasingly complex missions that 
will require a high degree of autonomy and autonomicity. 
These missions pose hereto unforeseen problems and raise 
issues that have not been well-addressed by the commu- 
nity. Assuring success of such missions will require new 
software development techniques and tools. This paper dis- 
cusses some of the challenges that NASA and the rest of 
the software development community are facing in devel- 
oping these ever-increasing ty complex systems. We give 
an overview of a proposed NASA mission as well as tech- 
niques and tools that are being developed to address au- 
tonomic management and the complexity issues inherent in 
these missions. 

1 An Historic Problem 

The realization that software development has lagged 
greatly behind hardware is hardly a new one [2], Brooks, in 
a widely-quoted article [3], warns of complacency in soft- 
ware development. He stresses that, unlike hardware de- 
velopment, we cannot expect to achieve great advances in 
productivity in software development unless we concentrate 
on more appropriate development methods. Harel, in an 
equally influential paper, written as a rebuttal to Brooks [6] 
points to developments in CASE and visual formalisms [5] 
as potential “bullets” (solutions). 

Clearly there have been significant advances in software 
engineering tools, techniques, and methods, since the time 
of Brooks’ and Harel’s papers. In many cases, however, 
the advantages of these developments have been mitigated 
by corresponding increases in demand for greater, more 
complex, functionality, stricter constraints on performance 
and reaction times, and attempts to increase productivity 
and reduce costs, while simultaneously pushing systems re- 
quirements to their limits. NASA, for example, continues 
to build more and more complex systems, with impressive 
functionality, and increasingly autonomous behavior. In the 
main, this is essential. NASA missions are pursuing sci- 
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entific discovery in ways that will require automated, au- 
tonomous systems. While manned exploration missions are 
clearly in NASA’s future (such as the Exploration Initia- 
tive’s plans to return to the moon and put man on Mars), 
for reasons we will explain below, several current and fu- 
ture NASA missions necessitate autonomous behavior by 
unmanned spacecraft [9]. 

We will describe some of the challenges for software en- 
gineering emerging from new classes of complex systems 
being developed by NASA and others. We will discuss 
these with reference to a NASA concept mission that is ex- 
emplary of many of these new systems. Then, in Section 3 
we will present some techniques that we are addressing, in- 
cluding autonomic management, which may contribute to 
finding the Silver Bullet. 

2 Challenges of Future NASA Missions 

Future NASA missions will exploit new paradigms for 
space exploration, heavily focused on the (still) emerging 
technologies of autonomous and autonomic systems. Tra- 
ditional missions, reliant on one large spacecraft, are being 
replaced with missions that involve several smaller space- 
craft, operating in collaboration, analogous to swarms in 
nature. This offers several advantages: the ability to send 
spacecraft to explore regions of space where traditional craft 
simply would be impractical, greater redundancy and, con- 
sequently, greater protection of assets, and reduced costs 
and risk, to name but a few. Planned missions entail, for 
example, the use of several unmanned autonomous vehicles 
(UAVs) flying approximately one meter above the surface 
of Mars, which will cover as much of the surface of Mars 
in a few seconds as the now famous Mars rovers did in their 
entire time on the planet. 

These new approaches to exploration missions simulta- 
neously pose many challenges. The missions will be un- 
manned and necessarily highly autonomous. They will 
also exhibit the properties of autonomic systems, be- 
ing self-protecting, self-healing, self-configuring, and self- 
optimizing. Many of these missions will be sent to parts 


of the solar system where manned missions are simply not 
possible, and to where the round-trip delay for communi- 
cations to spacecraft exceeds 40 minutes, meaning that the 
decisions on responses to problems and undesirable situa- 
tions must be made in situ rather than from ground control 
on Earth. The degree of autonomy that such missions will 
possess would require a prohibitive amount of testing to en- 
sure correct behavior. Furthermore, learning and continual 
improvements in performance by each individual platform 
will mean that emergent behavior patterns simply cannot be 
fully predicted. 

2.1 ANTS: A NASA Concept Mission 

One of these future NASA missions is the Autonomous 
Nano-Technology Swarm (ANTS) mission, which will in- 
volve the launch of a swarm of autonomous pico-class (ap- 
proximately 1kg) spacecraft that will explore the asteroid 
belt for asteroids with certain characteristics. Figure 1 gives 
an overview of the ANTS mission [17], A transport ship, 
launched from Earth, will travel to a point in space where 
gravitational forces on small objects (such as spacecraft) are 
all but negligible. From this point, termed a Lagrangian, 
1000 spacecraft that have been assembled en route from 
Earth, will be launched into the asteroid belt. Because of 
the nature of the asteroid belt, spacecraft will experience a 
significant risk of collision with asteroidal bodies. Further, 
since the individual spacecraft have no onboard propulsion, 
and can maneuver only by using solar sails, collisions be- 
tween spacecraft are possible during exploration operations 
around asteroids, so that 60% to 70% of them may be lost. 

Because of their small size, each spacecraft will carry 
just one specialized instrument for collecting a specific type 
of data from asteroids in the belt. As a result, spacecraft 
must cooperate and coordinate using a hierarchical social 
behavior analogous to colonies or swarms of insects, with 
some spacecraft directing others. To implement this mis- 
sion, a heuristic approach is being considered that provides 
for a social structure based on the notion of a hierarchy 
among the spacecraft. Artificial intelligence technologies 
such as genetic algorithms, neural nets, fuzzy logic and on- 
board planners are being investigated to assist the mission 
to maintain a high level of autonomy. Crucial to the mission 
will be the ability to modify its operations autonomously to 
reflect the changing nature of the mission and the distance 
and low bandwidth communications back to Earth. 

2.2 Problematic Issues 
2.2.1 Size and Complexity 

While the use of a swarm of miniature spacecraft is es- 
sential for the success of ANTS (by enabling many points 
of simultaneous observation and data collection), it also 



Figure 1 . NASA’s Autonomous Nano Technol- 
ogy Swarm (ANTS) mission scenario. 


poses several problems in terms of adding significantly to 
the complexity of the mission. The mission will launch 
1000 pico-class spacecraft. Even with a possible loss rate of 
60% to 70%, we expect to have several hundred surviving 
spacecraft, all of which must be kept organized in effective 
groups that will collect science data and make decisions as 
to which asteroids warrant further investigation. 

2.2.2 Emergent Behavior 

In swarm-based systems, a group of interacting agents (of- 
ten homogeneous or near homogeneous) are developed to 
take advantage of their emergent behavior. In these sys- 
tems, each of the agents is given certain parameters that it 
tries to maximize. Intelligent swarms [1] involve the use of 
swarms of simple intelligent agents. Swarms have no cen- 
tral controller: they are self-organizing based on the emer- 
gent behaviors of the simple interactions. There is no ex- 
ternal force directing their behavior and no one agent has a 
global view of the intended macroscopic behavior. Though 
current NASA swarm missions are not true swarms as de- 
scribed above, they do have many of the same attributes 
and may exhibit emergent behavior. In addition, there are 
a number of government projects that are looking at true 
swarms to accomplish complex missions. 

2.2.3 Autonomy 

Autonomous operation is essential for the success of the 
ANTS mission. Round trip communications delays of up 
to 40 minutes, and limited bandwidth on communications 
links with Earth, mean that control from the ground is im- 
possible. The data concerning a swarm emergency situa- 
tion (e.g., a projected collision between a spacecraft and 


an asteroid or between two spacecraft in the swarm) would 
already be stale and effectively unusable when finally re- 
ceived by ground control personnel. Furthermore, the actual 
swarm situation would likely have changed so much after 
the additional signal propagation delay on any instructions 
transmitted back to the swarm that the attempt by ground 
control to handle the emergency would be invalid and inef- 
fective. 

Autonomy implies an absence of centralized control. In- 
dividual ANTS spacecraft will operate autonomously under 
the control of that subgroup’s ruler. That ruler will itself au- 
tonomously make decisions regarding asteroids of interest, 
and formulate plans for continuing the mission of collect- 
ing science data. The success of the mission is predicated 
on the validity of the plans generated by the rulers, and re- 
quires that the rulers generate sensible plans that will collect 
valid science data, and then make valid informed decisions. 

That autonomy is possible is not in doubt. What is in 
doubt is that autonomous systems can be relied upon to op- 
erate correctly, in particular in the absence of a full and 
complete specification of what is required of the system. 
Our goal is to address this crucial issue. 

2.2.4 Testing and Verification 

One of the most challenging aspects of using swarms is how 
to verify that the emergent behavior of such systems will 
be proper and that no undesirable behaviors will occur. In 
addition to emergent behavior in swarms, a large number of 
concurrent interactions occur between the agents that make 
up the swarms. These interactions can also contain errors, 
such as race conditions, that are very difficult to detect until 
they occur. Once they do occur, it can also be very difficult 
to recreate the errors, since they are usually data and time 
dependent. 

3 Some Potentially Useful Techniquess 
3.1 Autonomicity 

Autonomy may be considered as having the properties 
of self-governance and self-driven-ness, i.e., control over 
one’s goals. Autonomicity is having the ability to self- 
manage through properties such as self-configuring, self- 
healing, self-optimizing, and self-protecting [4, 10, 14], 
These are achieved through other self-properties such as 
self-awareness (including environment awareness), self- 
monitoring, and self-adjusting [15]. 

Increasingly, self-management is seen as the only viable 
way forward to cope with the ever increasing complexity 
of systems. From one perspective, self-management may 
be considered a specialization of self-governance, i.e., au- 
tonomy where the goals/tasks are specific to management 


roles [16]. Yet from the wider context, an autonomic ele- 
ment (AE), consisting of an autonomic manager and man- 
aged component, may still have its own specific goals, but 
also additional responsibility of management tasks, in par- 
ticular to the wider system environment. 

It is envisaged that in an autonomic environment, the 
AEs communicate to ensure a managed environment that 
is reliable and fault tolerant and meets high level specified 
policies (with an overarching vision of system- wide policy- 
based self-management). This may result in AEs moni- 
toring or “watching out for” other AEs. In terms of au- 
tonomy and the concern of undesirable emergent behavior, 
an environment that dynamically and continuously moni- 
tors can assist in detecting race conditions and reconfig- 
uring to avoid damage (self-protecting, self-healing, self- 
configuring, etc.). As such, Autonomicity becoming main- 
stream in the industry can only assist to improve techniques, 
tools, and processes for autonomy [14]. 

3.2 Hybrid Formal Methods 

To overcome the complexity and many other issues in de- 
veloping future NASA missions, formal specification tech- 
niques and formal verification will need to play vital roles. 
NASA is currently investigating the use of formal meth- 
ods and formal techniques for verification and validation of 
these classes of mission. The primary role of formal meth- 
ods will be in the specification and analysis of forthcoming 
missions, with a further role in software assurance and proof 
of correctness of the behavior of a swarm, whether or not 
this behavior is emergent (as a result of composing a num- 
ber of interacting entities, producing behavior that was not 
foreseen). Formal models derived may also be used as the 
basis for automating the generation of much of the code for 
the mission [8]. A current project. Formal Approaches to 
Swarm Technologies (FAST), is investigating the require- 
ments of appropriate formal methods for use in such mis- 
sions, and is beginning to apply these techniques to speci- 
fying and verifying parts of the ANTS mission. 

Hybrid, or integrated, formal approaches have been very 
popular in specifying concurrent and agent-based systems. 
No doubt this is due to the monolithic systems that most for- 
mal methods were developed to specify and verify. Hybrid 
approaches often combine a process algebra or logic-based 
approach with a model-based approach. The process alge- 
bra or logic-based approach allows for easy specification of 
concurrent systems, while the model-based approach pro- 
vides strength in specifying the algorithmic part of a sys- 
tem. 

As part of the FAST project, new hybrid formal methods 
are being investigated to address complex NASA missions 
including swarms. 


3.3 Automatic Programming 

For many years, automatic programming has referred, 
primarily, to the use of very high-level languages to de- 
scribe solutions to problems, which could then be translated 
down and expressed as code in more familiar programming 
languages. Pamas [11] implies that the term is glamorous, 
rather than having any real meaning, precisely because it is 
the solution that is being specified/ather than the problem 
that must be solved. 

Autonomous and autonomic systems, exhibiting com- 
plex emergent behavior cannot, in general, be fully specified 
at the outset. The roles and behaviors of the system will 
vary greatly over time. While we may try to write speci- 
fications in such a manner that constrain the system, it is 
clear that not all behavior can be specified in advance. This 
is particularly true of systems exhibiting self-management 
The classes of system we are discussing will often require 
code to be generated, or modified, during execution. Con- 
sequently, automatic code generation will be required. 

Several tools already exist that successfully generate 
code from a given model. Unfortunately, many of these 
tools have been demonstrated to generate code, portions of 
which are never executed, or portions of which cannot be 
justified from either the requirements or the model. More- 
over, existing tools do not and cannot overcome the funda- 
mental inadequacy of all currently available automated de- 
velopment approaches, which is that they include no means 
to establish a provable equivalence between the require- 
ments stated at the outset and either the model or the code 
they generate. That is why, we believe, future approaches to 
automatic code generation, in particular for autonomic sys- 
tems, must be based on Formal Requirements-Based Pro- 
gramming. 

3.4 Formal Requirements Based Programming 

Requirements-Based Programming refers to the devel- 
opment of complex software (and other) systems, where 
each stage of the development is fully traceable back to the 
requirements given at the outset. 

Requirements-Based Programming ensures that there is 
a direct mapping from requirements to design, and that this 
design (model) may then be used as the basis for automatic 
code generation. In fact. Formal Requirements-Based Pro- 
gramming, coupled with a graphical representation for sys- 
tem requirements (e.g., UML use cases) possesses the fea- 
tures and advantages of a visual formalism described by 
Harel [5]. 

R2D2C, or Requirements-to-Design-to-Code [7, 12], is 
a NASA patent-pending approach to Requirements-Based 
Programming. In R2D2C, engineers (or others) may write 
specifications as scenarios in constrained (domain-specific) 


natural language, or in a range of other notations (includ- 
ing UML use cases). These will be used to derive a formal 
model that is guaranteed to be equivalent to the require- 
ments stated at the outset, and which will subsequently be 
used as a basis for code generation. 

R2D2C is unique in that it allows for full formal devel- 
opment from the outset, and maintains mathematical sound- 
ness through all phases of the development process, from 
requirements through to automatic code generation. 

3.5 Tool support 

John Rushby [13] argues that tools are not the most im- 
portant thing about formal methods, they are the only im- 
portant thing about formal methods. Although we can sym- 
pathize, we do not support such an extreme viewpoint. For- 
mal methods would not be practical without suitable repre- 
sentation notations, proof systems (whether automated and 
supported by tools, or not), a user community, and evidence 
of successful application. 

We do agree, however, that tool support is vital, and not 
just for formal methods. Structural design methods “took 
off’ when they were “standardized”, in the guise of UML. 
But it was only with the advent of tool support for UML that 
it became widely used. The situation is analogous to high 
level programming languages: while the community was 
well convinced of their benefits, it was only with the avail- 
ability of commercial compilers that they became widely 
used. 

Tools are emerging for the development of complex 
agent-based systems such as Java-based Aglets and tools 
for autonomic systems. For automatic code generation and 
formal Requirements-Based Programming to be practical, 
the development community will need commercial-quality 
tools. Similarly, the autonomic management of complex 
systems will require adequate tool support. 

4 Conclusion 

We have re-iterated several problems facing the soft- 
ware development community. Unfortunately, while well 
known for many decades, these issues still prevail. More 
importantly, new classes of systems — namely complex, 
highly-distributed autonomous systems and their autonomic 
management — will pose many other challenges, which yet 
remain unaddressed. 

We have described one concept system that exemplifies 
forthcoming classes of complex autonomous systems that 
NASA, and others, are developing. These pose hereto un- 
foreseen problems and raise issues that have not been well- 
addressed by the community. We have mentioned some 
techniques under development by NASA that may be fruit- 
ful in addressing these problems. 
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